Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-010.txt

Text File | 1992-11-18 | 31.7 KB | 855 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sun, 08 Mar 92       Volume 1 : Issue 10

Today's Topics:

    Question: How to use Text/styl resources
    FSOpen problem with Pathworks/Appleshare
    Updating QuickTime pictures in HyperCard
     Is FlushVol still recommended?
     A QuickTime puzzlement
     Macintalk (was Re: Is FlushVol still recommended?)
    COMPILERS AND INLINE ASM.
    Sound.h w/THINK C 5.0.2
    SIOW in MPW


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac directory on ftp.cs.uoregon.edu.
This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jonathan Greenfield)
Subject: Question: How to use Text/styl resources
Date: 22 Jan 92 16:21:41 GMT
Organization: CIS Dept., Syracuse University

I've been unable to locate information on using Text/styl resources.  I
have checked both Spinside Macintosh (Vols. 1-5) and Inside Mac Vol. 6
for information on Text/styl resources and have found essentially nothing.

Could someone send me some pointers to such information, or perhaps, send
me a sample code segment (preferably in Pascal) that displays a Text/styl
resource in a dialog box or alert?

Thanks.


greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Ed Swierk)
Subject:  Question: How to use Text/styl resources
Date: 23 Jan 92 00:48:45 GMT
Organization: Cornell University

In article <[e-mail]>,
[e-mail] (Jonathan Greenfield) writes:
> I've been unable to locate information on using Text/styl resources.  I
> have checked both Spinside Macintosh (Vols. 1-5) and Inside Mac Vol. 6
> for information on Text/styl resources and have found essentially nothing.

There is a little blurb somewhere about them in one of the IM's, I think 5.
Nothing too informative, though.

This is what I've figured out from what there is in IM 5: 'TEXT' resources
are just hunks of text that you can load in with GetResource and do with as
you please. 'styl' resources are called "style scraps," and are what
applications put on the Clipboard along with 'TEXT' resources. They are
represented by the data type StScrpRec (see IM 5, p. 265).

> Could someone send me some pointers to such information, or perhaps, send
> me a sample code segment (preferably in Pascal) that displays a Text/styl
> resource in a dialog box or alert?

Here is a short program written with THINK Pascal that dumps a 'TEXT' and
'styl' resource combo to the Drawing window. It can be easily adapted to
draw to a window of your choice.

PROGRAM TestEdit;

    VAR
        rsrcRefNum: INTEGER;
        aTEHandle: TEHandle;
        aStScrpHandle: StScrpHandle;
        textHandle: Handle;
        destRect, viewRect: Rect;

BEGIN

{ set up }
    rsrcRefNum := OpenResFile('TestEdit.rsrc');
    IF ResError <> noErr THEN
        SysBeep(50);

{ make a new TERec }
    SetRect(destRect, 0, 0, 400, 300);
    SetRect(viewRect, 0, 0, 400, 300);
    aTEHandle := TEStylNew(destRect, viewRect);

{ get the 'TEXT' resource }
    textHandle := GetResource('TEXT', 128);

{ get the 'styl' resource }
    aStScrpHandle := StScrpHandle(GetResource('styl', 128));

{ insert the text into the TERec }
    MoveHHi(textHandle);
    HLock(textHandle);
    TEStylInsert(textHandle^, GetHandleSize(textHandle), aStScrpHandle,
aTEHandle);
    HUnlock(textHandle);

{ draw the text }
    TEUpdate(viewRect, aTEHandle);

{ clean up }
    DisposHandle(textHandle);
    ReleaseResource(Handle(aTEHandle));
    ReleaseResource(Handle(aStScrpHandle));
    CloseResFile(rsrcRefNum);

END.

--
                Ed Swierk
       Cornell University
[e-mail]



- -------------------------

From: [e-mail]
Subject:  Question: How to use Text/styl resources
Date: 23 Jan 92 05:09:38 GMT
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Jonathan Greenfield) writes:
> Could someone send me some pointers to such information, or perhaps, send
> me a sample code segment (preferably in Pascal) that displays a Text/styl
> resource in a dialog box or alert?

Use ResEdit to create a TEXT/styl pair; call TEStylNew to create a styled
text edit record; and pull the resources into your program:

  procedure GetStylText (teHdl: TEHandle; id: Integer);
  var hStyl, hText: Handle;
  begin
    hText := GetResource('TEXT', id);
    hStyl := GetResource('styl', id);
    if (hText <> nil) and (hStyl <> nil) then
      begin
        HLock(hText);
        HLock(hStyl);
        TEStylInsert(hText^, SizeResource(hText), StScrpHandle(hStyl), teHdl);
        HUnlock(hText);
        HUnlock(hStyl);
      end
    else
      begin
        ErrorAlert('Dave, what are you doing, Dave?');
        ExitToShell
      end
  end;

Call TEUpdate to cause the styled text to be drawn in your view rectangle.

The styl record stores font details by font number, which varies from system
to system. This is a problem for which I don't have a good answer.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "Now why would Mike Wallace be standing around on MY porch with a TV crew?"|
o----------------------------------------------------------------------------o



---------------------------

From: [e-mail]
Subject: FSOpen problem with Pathworks/Appleshare
Date: 21 Jan 92 15:20:19 GMT
Organization: McDnDSpaceSys, Huntington Bch, CA

Hi all,

  I have a (hopefully) simple problem that is stopping me cold with accessing
a DEC Pathworks volume with FSOpen. Here's the deal:

A VAX user creates a text file and transfers it to a given directory. This
directory is also one folder down from the root of a Pathworks volume. The
volume is mounted to a Mac. This folder has a *lot* of files in it (3000+),
which is why we placed it one level down (anyone who's waited for a Pathworks
volume to open on a Mac knows why).

  The code stub gets a full pathname (i.e. "Vol:folder:thefile.lis"), does a
GetVol on the volume to get the VolID, and then does an FSOpen with the pathname
and VolID. This returns a -43 (file not found). (And yes, I've run it with
LightsBug on to make sure the pathname is right.)

Now for the interesting part... If the pathname is fed to MSWord, (via use of
the Hypercard "open <file> with <app>")it will open the file. After Word has
opened the file once, the FSOpen *works*!!!!!! Can someone shed some light on
why this is the case, and how we can open the file directly?

We're using Pathworks 1.0, Think Pascal 4.0, System 6.0.5 & 7 on IIcx's.

Thanks in advance...!


Jeff Johnson
[e-mail]


- ---------------------------------------------------------------------------
....About that Pathworks upgrade supposed to be coming....the one for 7....
....November...... uh, which century was that, exactly????
Digital has it now, but who says *YOU'LL* be able to get it??????



- -------------------------

From: [e-mail] (Jeff E Mandel)
Subject:  FSOpen problem with Pathworks/Appleshare
Date: 22 Jan 92 23:38:57 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> [e-mail]
writes:
>
>A VAX user creates a text file and transfers it to a given directory. This
>directory is also one folder down from the root of a Pathworks volume. The
>volume is mounted to a Mac. This folder has a *lot* of files in it (3000+),
>which is why we placed it one level down (anyone who's waited for a Pathworks
>volume to open on a Mac knows why).
>
>  The code stub gets a full pathname (i.e. "Vol:folder:thefile.lis"), does a
>GetVol on the volume to get the VolID, and then does an FSOpen with the
pathname
>and VolID. This returns a -43 (file not found). (And yes, I've run it with
>LightsBug on to make sure the pathname is right.)
>
>Now for the interesting part... If the pathname is fed to MSWord, (via use of
>the Hypercard "open <file> with <app>")it will open the file. After Word has
>opened the file once, the FSOpen *works*!!!!!! Can someone shed some light on
>why this is the case, and how we can open the file directly?
>

I imagine Bob Denny can give you a more definitive answer, but PathWorks
doesn't know about files moved into the directory until the file system gets
properly tweaked to see what's in the directory. I don't know exactly which
call it is that does this, however.
I'd probably try PBGetCatInfo on the directory, then the FSOpen, and see if it
helps.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  FSOpen problem with Pathworks/Appleshare
Date: 23 Jan 92 04:46:54 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jeff E Mandel)
complains about not being able to open a file on a PathWorks volume that
was just created/moved there from the VMS side.

Funnily enough, I have hit a similar problem trying to open text files
from the MPW Shell (using its "Open" command) immediately after renaming
them to a Pathworks folder using VMS RENAME in a Telnet window. In every
case, I found that doing a wildcard "Files" command (directory listing)
on the folder caused the Pathworks server to notice the file, and a subsequent
"Open" would succeed.

Perhaps HyperCard 2.1's "open <document> with <app>" is triggering some
sort of directory lookup, which is equivalent in effect. Whatever it is,
a straight PBOpen call certainly isn't enough for PathWorks to notice the
new file. Perhaps it should be.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00



---------------------------

From: [e-mail] (William Alves)
Subject: Updating QuickTime pictures in HyperCard
Date: 22 Jan 92 03:25:57 GMT
Organization: University of Southern California, Los Angeles, CA

When I use direct QuickTime movies in HyperCard or display single images
with the QTPict XCMD, parts of the image may disappear when HyperCard
updates the card window. For example, if I move the card half off the
screen and back on, half of any QuickTime picture that was displayed
is gone. If I activate a different card window and bring it to the front,
the picture in the QuickTime stack window completely disappears.

I assume this is because HyperCard has no knowledge of the QuickTime
picture when updates are sent to the GrafPort of the window. Of course
this is not such a problem while movies are running because the picture
is constantly being changed. But when a movie is paused or I am displaying
still images, it is definitely a problem.

Is there any way around this problem? Thanks for your help!

Bill Alves



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Updating QuickTime pictures in HyperCard
Date: 23 Jan 92 04:51:50 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (William Alves)
complains about how still images drawn directly to a HyperCard card window
don't refresh correctly on a window update.

I've seen workarounds which involved calling the external periodically
in an idle handler and telling it to unconditionally redraw the entire image,
say every 3 seconds.

The basic problem is that there is no way to trap update events in
HyperTalk. I think this is sorely needed.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00



- -------------------------

From: [e-mail] (William Alves)
Subject:  Updating QuickTime pictures in HyperCard
Date: 23 Jan 92 05:22:00 GMT
Organization: University of Southern California, Los Angeles, CA

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (William Alves)
>complains about how still images drawn directly to a HyperCard card window
>don't refresh correctly on a window update.
>
>I've seen workarounds which involved calling the external periodically
>in an idle handler and telling it to unconditionally redraw the entire image,
>say every 3 seconds.
>
This would be more workable if it were not for the fact that I usually have
several stacks open in different windows (using HyperCard 2.1). When another
window is activated, the QuickTime picture disappears AFTER the suspendstack
message is sent. The stack that is activated has no way of knowing that an
inactive window has a QuickTime picture that must be updated.

>The basic problem is that there is no way to trap update events in
>HyperTalk. I think this is sorely needed.

Agreed. Thanks for the reply.

Bill Alves



- -------------------------

From: [e-mail] (Paul Fritze)
Subject:  Updating QuickTime pictures in HyperCard
Date: 24 Jan 92 06:41:19 GMT
Organization: Chemistry Department, Melbourne University, AUS.

>I've seen workarounds which involved calling the external periodically
>in an idle handler and telling it to unconditionally redraw the entire image,
>say every 3 seconds.
>The basic problem is that there is no way to trap update events in
>HyperTalk. I think this is sorely needed.

I have used a kludge quite successfully when putting colour images over a card
by using an XFCN to return the value of a single pixel that indicates the image
has been at least partially cleared. The idle script then refreshes the
picture only when necessary. This works best for dialog boxes and the like
which are predictable in their behaviour.

If anyone is interested I will look up the details.



---------------------------

From: [e-mail] (Tonny Yu)
Subject:  Is FlushVol still recommended?
Date: 22 Jan 92 17:02:31 GMT
Organization: Just me

I am looking for source code to help build a speech synthesis program.  I heard
that MacinTalk has some source code support.  Does anyone know how I can get
hold of it? Are there any other code sources?
Any experiences with speech synthesis?

I would appreciate any advice, suggestions, or references.  Thanks.


    -Tonny



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Is FlushVol still recommended?
Date: 25 Jan 92 21:57:29 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Tonny Yu) writes:
>
> I am looking for source code to help build a speech synthesis program.  I heard
> that MacinTalk has some source code support.  Does anyone know how I can get
> hold of it? Are there any other code sources?
> Any experiences with speech synthesis?
>
> I would appreciate any advice, suggestions, or references.  Thanks.

Let's see if I got it right this time :-) (Kent is reading an APDALog,
hopefully this semi-old one is right...). Yes, it's listed in the APDA
product line. And the package should include examples of how to use
the libraries.

Anyway, a word of warning. Apple doesn't guarantee anymore that MacinTalk
works properly under System 7. Please read Tech Note 268 that explains
the technical issues.

I also heard a rumor that the TalkingMoose people got MacinTalk work
properly under System 7.

Kent
- -
not speaking for DTS, nope, no way.



---------------------------

From: [e-mail] (Ivan M CaveroBelaunde)
Subject:  A QuickTime puzzlement
Date: 19 Jan 92 23:06:40 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

><Playback problems wih "Hollywood" moov>
>I assumed initially that this had something to do with key frames, and
>that QuickTime was simply restarting the decompression sequence from a
>movie frame that didn't depend on any previous movie frame. However, this
>appears not to be true, because on further investigation I found that:
>   * "Hollywood" is not temporally compressed (every frame is a key frame),
>and
>   * I have not encountered the same phenomenon with any other movie,
>     even though I've tried ones both with and without temporal compression.
>Can anybody shed some light on my puzzlement here? The fact that my code
>seems to work with every other movie suggests there's something unusual
>about the format of this one. Doesn't it?

I haven't had a chance to look at the Hollywood movie, but the QuickTime
MooV format has changed slightly during beta, and that might be it. You
might want to load and resave the movie to a different file using simple
player (maybe even flattening it). If that doesn't fix it, you could
use ConvertToMooV to recompress it using the new compressors (the data
stream format for rpza changed at least once, I believe).

- -
Ivan Cavero Belaunde ([e-mail])
Visualist, DiVA Corporation

        "A tu escuela llegue, sin entender por que llegaba,
        En tus salones encuentro, mil caminos y encrucijadas,
        Y aprendo mucho, y no aprendo nada,
        Maestra vida, camara', te da, te quita, te quita y te da."
                -Ruben Blades, "Maestra Vida"



- -------------------------

From: [e-mail] (Ivan M CaveroBelaunde)
Subject:  Image compression questions
Date: 27 Jan 92 05:13:44 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Kenneth Knight) writes:

>In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>>Can someone clear up some lingering bits of confusion I have about the
>>QuickTime Image Compression Manager? This has to do with compressing and
>>decompressing image sequences, and exactly what some flag bits mean.
>>
>>There appear to be three "CodecFlags" bits that have something to do
>>with temporally compressed sequences. These are codecFlagUseImageBuffer,
>>codecFlagUpdatePrevious, and codecFlagUpdatePreviousComp.
>>

Not positive, but my understanding is that the ICM, when compressing
sequences, keeps around the previous image and a compressed version of
it (one of them might be purgeable or something, but I'm not sure. It's
been a while since I've dealt with that part of QT). Anyhow, when
you call CompressSequenceFrame with codecFlagUpdatePrevious it updates the
previous uncompressed image, and with codecFlagUpdatePreviousComp it updates
the previous compressed image. Apple's sample code recommended using both
(since using the previously compressed image for frame differencing results
in more accurate and compact frame differencing) by passing
codecFlagUpdatePrevious+codecFlagUpdatePreviousComp.

>On a related issue I don't see what difference using the bestSpeedCodec,
>bestCompressionCode, or bestFidelityCodec make. I've tried changing those
>bits around and done photo (JPEG) compressions on several 24-bit images and
>the results have yet to change from what I was getting when the that bit was
>simply set to anyCodec. Am I just missing something here?

They will do nothing with vanilla QuickTime. If you have multiple compressors
of one type installed, however, (such as the GC-based video compressor or
Storm's hardware JPEG compressor), bestSpeedCodec will pick the fastest
codec of that type (in the above examples, the GC-based rpza and Storm's jpeg
over the native QuickTime ones).

The codecinfo resources that each codec makes available to the ICM states,
among other things, speed, fidelity and compression ratings to allow the
ICM to pick compressors when passed bestSpeedCodec et.al.

Hope this helps. Back to the coding cave.

--
Ivan Cavero Belaunde
Visualist, DiVA Corporation

    "A tu escuela llegue, sin entender por que llegaba,
    en tus salones encuentro, mil caminos y encrucijadas,
    y aprendo mucho ... y no aprendo nada ...
    Maestra vida, camara, te da, te quita, te quita y te da."
        -Ruben Blades, "Maestra Vida"



---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Macintalk (was Re: Is FlushVol still recommended?)
Date: 22 Jan 92 23:05:29 GMT
Organization: Kalamazoo College

[e-mail] (Tonny Yu) writes:
>I am looking for source code to help build a speech synthesis program.  I heard
>that MacinTalk has some source code support.

Sadly, not true.  Apple bought the _object_ code for Macintalk for the
unveiling of the original Mac, so Steve Jobs could have it speak.  They
do not own the source code.  Macintalk has been patched twice in the
last eight years to remain (semi-) compatible with the changing system
software, but the patches were applied to the object code.

>Does anyone know how I can get
>hold of it? Are there any other code sources?

There are no other free text-to-speech modules for the Macintosh.  (In
fact, I don't think there are any at all, but I won't stick my neck
out.)
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy



- -------------------------

From: [e-mail] (Larry Shupe)
Subject:  Macintalk (was Re: Is FlushVol still recommended?)
Date: 23 Jan 92 16:17:54 GMT
Organization: University of Washington

> [e-mail] (Tonny Yu) writes:
> I am looking for source code to help build a speech synthesis program.
> I heard that MacinTalk has some source code support.
>
> Does anyone know how I can get
> hold of it? Are there any other code sources?

There is a MacinTalk Development Package available from APDA.
It allows you to call the MacinTalk routines from within your
own program.  I've used this package on a Mac+ to write an
INIT that speaks to you at startup time.  This program even
functions under system 7.0 on the Mac+.  I have no idea if
it will work on newer machines, and I doubt if it will continue
to function much longer.

Larry Shupe
[e-mail]



---------------------------

From: [e-mail] (Giovanni Kolobari)
Subject: COMPILERS AND INLINE ASM.
Date: 23 Jan 92 02:14:41 GMT
Organization: University of Illinois at Chicago


 Howdy fellow MacAddicts...
I was writting a CODE resource the other day, and due to the fact
that it was quite convoluted, I had to take care of some register
saving manually. I am using
THINK Pascal 3.0.2 (system 6.0.7) The resource bombed for the
obvious reasons (some scratch registers were considered non-scratch,
etc, etc) I examined the code with ResEdit, figured out which registers
TP saves, and manually inserted he other saves with InLines.
Finally after saving all the remaining registers I got it to work.
I am sure that I could have done the same using "RememberA0",..etc,
but believe me, it needed more than that. Anyway.
What came to mind was comparing the Assembly capabilities of TC with
those of TP. It is more than obvious that TP lacks badly in that area.
I was trying to figure out a scheme that would allow me to "replicate"
in a sense the Inline capability that TC has, but what I came up
was obviously pretty limited: Use ASM , the use TP utility '.rel2lib'
and then include it as a library to my project. Still, the state of
the registers is pretty much unknown, unless someone KNOWS in advance
what TP does before it calls ANY or a PARTICULAR subroutine.
 Of course one can use InLines, but this is cumbersome, since *some*
sort of assembler has to be used to translate the mnemonics to ops.
 The big question is, is it THAT hard to implement an inline assembler
feature in THINK P? Are there maybe some technical considerations that
have to be taken into account? From what I've seen so far, the TP compiler
meets and exceeds many of the standards of compiler design that we poor
oldtimers were taught at school. (Speed vs error reporting accuracy, etc)
So, it is kind of obvious to me that the gurus who designed such a monster,
will have nil trouble getting it to do an inline assembly trick.
One other issue of importance, here, is of course that of taste:
 Supposedly C allows one more freedom than Pascal. My opinion is
(only MY opinion, of course) that since all the new goodies like
type coersion, pointer casting, objects and Inline code came out,
the issue of "power" has been reduced to pretty much an issue of
taste or style if you will.
 So, why do the C programmers have to be more priviledged on that?
I for one, have been using RatFor for quite a while, so do not
need C perse. In the worst case, lets pay more for a THINK P compiler
with Inline ASM. I don't think its such a proposterous idea.
 So, how about it? Any opinions? Can it be done?
G.K. Professional Schizophrenic.
- ---------------------------------------
Everyday you read, see, hear, smell taste and feel things.
If you like the experience, you remember it.
What happens when you DO NOT like the experience?
You forget it, right? WRONG.
Your subconscious remembers it...So,
just make sure it doesn't overflow...
- -------------------------------------------------
The opinions above are mine. Being a Schizophrenic, I am not
liable to persecution. UIC has nothing to do with them.



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  COMPILERS AND INLINE ASM.
Date: 23 Jan 92 16:13:03 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> Giovanni Kolobari <[e-mail]> writes:

> The big question is, is it THAT hard to implement an inline assembler
>feature in THINK P? Are there maybe some technical considerations that
>have to be taken into account? From what I've seen so far, the TP compiler
>meets and exceeds many of the standards of compiler design that we poor
>oldtimers were taught at school. (Speed vs error reporting accuracy, etc)
>So, it is kind of obvious to me that the gurus who designed such a monster,
>will have nil trouble getting it to do an inline assembly trick.

    There's nothing intrinsically wrong with an inline assembler in
Pascal - there are, of course, new keywords to be introduced, and new
semantics to be considered, and new syntax, but it's just code. However,
the current architecture of THINK Pascal makes it very difficult to do
these things - such a fundamental change to the compiler would require
equally core changes to the editor and debugger, as well.

R.



--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



---------------------------

From: [e-mail] (| particle man |)
Subject: Sound.h w/THINK C 5.0.2
Date: 23 Jan 92 05:04:53 GMT
Organization: University of Illinois at Urbana

When I include the 'out of the box' Sound.h file included
with TC 5.0.2, a syntax check of my code gives
an Enumeration Constant too Big Error.

Here's the code checked as offensive:
#define twelfthRootTwo 1.05946309434

    rate22khz = 0x56EE8BA3,                 /* 22254.54545 in fixed-point */
    rate11khz = 0x2B7745D1,                 /* 11127.27273 in fixed-point */

Anyone have any workarounds? Did I set some compiler option improperly?

Thanks in advance....
                             -Scott


--

    "Laugha while you cana, Monkey Boy!" -Emilio Lizardo



- -------------------------

From: [e-mail] (Paul Potts)
Subject:  Sound.h w/THINK C 5.0.2
Date: 23 Jan 92 15:58:25 GMT
Organization: Advanced Workstation Lab, University of Michigan

In article <scott.696143107@phylo> [e-mail] (| particle man |) writes:
>When I include the 'out of the box' Sound.h file included
>with TC 5.0.2, a syntax check of my code gives
>an Enumeration Constant too Big Error.
>

This problem is caused by setting the int-size to 16 bits and then setting
the "enums are ints" option. Turn off the "enums are ints" or else change
the integer size (the latter is harder, since if you are using stdio or any
libraries you'll have to rebuild them with the longer ints).


--
         -Paul [e-mail]-
I! Hi'm a mtatng siugnaturei vir*ss. You cann~t reisth elping me  spre]d !



---------------------------

From: [e-mail] (Tom Santos)
Subject: SIOW in MPW
Date: 23 Jan 92 07:58:58 GMT
Organization: The TeleSoft BBS and Public Access Unix, [phone]

Has anyone managed to get the SIOW working?  Whenever I link in the
library, I get a linker error that claims that my jump table exceeds 32K.
I tried using the -ss linker option to increase the size of my segment
but it claims that there should be no problem with size.

I am using MPWPQR5... could that be the problem?

Tom

--
Tom Santos ([e-mail])



- -------------------------

From: [e-mail] (Robert Dominy)
Subject:  SIOW in MPW
Date: 27 Jan 92 23:31:39 GMT
Organization: NASA Goddard Space Flight Center

In article <[e-mail]>, [e-mail] (Tom Santos) writes:
>
> Has anyone managed to get the SIOW working?  Whenever I link in the
> library, I get a linker error that claims that my jump table exceeds 32K.
> I tried using the -ss linker option to increase the size of my segment
> but it claims that there should be no problem with size.

I'm using it without problem.  In addition to the -ss option for the
linker, you'll probably also need to set an option for the C compiler
(-bigseg, I believe).  Of course unless your source is very large or
you're linking in a LOT of libraries you shouldn't ever see this.  If
your source is large you might try segmenting it (use either #define pragma
segmentName in your source files or use the compiler option -s segmentName
when compiling).

- Bob



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  SIOW in MPW
Date: 29 Jan 92 20:38:51 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Robert Dominy) writes:
>
> In article <[e-mail]>, [e-mail] (Tom Santos) writes:
> >
> > Has anyone managed to get the SIOW working?  Whenever I link in the
> > library, I get a linker error that claims that my jump table exceeds 32K.
> > I tried using the -ss linker option to increase the size of my segment
> > but it claims that there should be no problem with size.
>
> I'm using it without problem.  In addition to the -ss option for the
> linker, you'll probably also need to set an option for the C compiler
> (-bigseg, I believe).  Of course unless your source is very large or
> you're linking in a LOT of libraries you shouldn't ever see this.  If
> your source is large you might try segmenting it (use either #define pragma
> segmentName in your source files or use the compiler option -s segmentName
> when compiling).

With MPW 3.2 you might use -wrap for creation of more jump table entries
in global data space, and -model far for full >32k segments. Don't use
both at the same time, you might trigger a interdimensional bug which
causes you to eat large quantities of aspirin.

Kent



---------------------------

End of C.S.M.P. Digest
**********************